Celestin Apprentice 4/Apprentice-Release4.iso/Information/Digests/CSMP Digest/volume 3/csmp-digest-v3-041/doubleCR.1

Text File | 1995-12-31 | 65.0 KB | 1,807 lines

C.S.M.P. Digest             Sat, 02 Jul 94       Volume 3 : Issue 41

Today's Topics:

        Detecting pre-68020 CPU for 68020 code
        Fast Animations (WAS: Fast full screen scrolling: impossible?)
        FlattenMovieData bug???
        Here's how to get OpenDoc
        How to know the cursor is into a polygon?
        PowerPC load-store (was Re: Fast full screen scrolling: impossible?)
        Q: Default button & Return key in Modeless Dialog
        Questions about Tmon?
        Saving PICT files - Here's CODE!!
        Scroll Bars in DLOG?
        Why should't you move baseAddrs?
        cntl-opt-esc
        scroll bars in modal dialogs



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (John Nagle)
Subject: Detecting pre-68020 CPU for 68020 code
Date: Thu, 16 Jun 1994 16:44:14 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

       Now that Symantec C++ is finally generating 68020 code when asked to
do so (for years, that switch did nothing), it's worth nothing that this
creates a problem in C++.

       In C programs, even Think C type programs, the first code executed
is in "main", so it's sufficient to check CPU type there.  But in C++,
static constructors run before "main".  Now that TCL is starting to use
constructors, and constructors are starting to work right in SC++, it's
more likely that code with a 68020 instruction might be executed before
"main".

       It's hard to deal with this in a way that's guaranteed to work
from the user program.  The check for 68020 needs to be made in
"CODE 1", the startup code block cranked out by the compiler for every
C++ program.  The user can't do this; only Symantec can.

       Anybody still care about pre-68020 machines, anyway?

                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 16 Jun 1994 19:10:32 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (John Nagle)
wrote:

>
>        Anybody still care about pre-68020 machines, anyway?

I don't, and I have two of them (a Plus, and a first 100-days Mac now in
512KE form).

However, there still are some Mac Portable owners around who do.  By now,
they must be used to programs which claim to require a 68020 or better
crashing on their machine, but it certainly isn't a nice thing to do to
them.

Do the constructors for the static objects actually *use* any 68020
instructions on a regular basis?  [Gestalt is available if you really want
to check in each such constructor...or in a phoney or real object you
arrange to have constructed first.]
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Fri, 17 Jun 1994 15:39:19 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (John W. Baxter) writes:
>Do the constructors for the static objects actually *use* any 68020
>instructions on a regular basis?  [Gestalt is available if you really want
>to check in each such constructor...or in a phoney or real object you
>arrange to have constructed first.]

      If you do any subscript calculations involving 2D arrays or arrays
of structures, you'll probably use the 32-bit multiply on a 68020.
On 68000 machines, a subroutine is called for every 32-bit multiply.

      You can't have an object you "arrange to have constructed first".
It's a feature of C++ that order of static constructor execution is
random across file boundaries.  ARM 12.6.1.

      You can't even call Gestalt from the constructor usefully unless
your class is a base class.  Base class constructors get called first,
so if your class is derived from another class, its constructor will be
called only after the base class constructor has already run.  It
won't help to override functions in the base class, either; the base class
versions will be called when the base class constructor is called.

      So there really isn't a sound way to do this.

                    John Nagle


                    John Nagle

---------------------------

>From [e-mail] (Christian Franz)
Subject: Fast Animations (WAS: Fast full screen scrolling: impossible?)
Date: Thu, 16 Jun 1994 09:14:27 GMT
Organization: Union Bank of Switzerland, CH

In article <1994Jun13.212936.24879@dal1>, [e-mail] wrote:
>
> In article <[e-mail]>, [e-mail] (Steve Taylor) writes:
> > From article <1994Jun12.232257.24853@dal1>, by [e-mail]:
> >> I think Chuck Yeager's Air Combat does this too. You can see interlacing
> >> in the terrain if you rock the plane back and forth.
> >>
> >> Sean
> >
> > Could someone describe this technique in more detail?  Are you talking
> > about leaving the other lines there and blitting the other half or
> > are you talking about doubling the height of the lines or what?
> > Thanks.
> >
> Well the description given above makes AstroChase 3D sound like CYAC,
> although the only thing I've seen in AstroChase 3D is the venetian blind
> style, rendering the frame onto every other line. Deliverance also has the
> option to do this, as does a game called Gate. It looks to me like CYAC
> does interlacing, i.e., there are no black lines alternating with the
> graphics, but if you rock the plane
> or turn rapidly, you can see the interlacing effect fairly easy in large
> polygons.

I'm currently developing a 3D space game and of course, I have the same
problems. I have tried many things, among them the alternate line modes
used by Astrochase (draw every other line) and CYAC (draw even lines on
even frames, odd lines on odd frames).

All these algorithms make one main assumption:
You draw the image in an off-screen buffer and after you are done drawing
it, you blast the image to screen. It usually takes three steps:

  1. erase offscreen buffer
  2. draw new frame offscreen
  3. blast offscreen image on-screen.

Tuning step 3 can speed up your program, but usually only by 1/6 max
(optimized blitting is usually one third of the time per frame and I
assume you double the speed of blitting by halving the lines to copy).

I have found out that there is a much better method (however, I doubt
if this technique can be applied to moving backgrounds as is the
main title of this thread). Actually I didn't find out myself but
Juri Munkki, Mac Animations Guru DeLuxe, did. Since my program uses
polygon-oriented graphics, you collect all your polygons as if you
would draw them. Then you compare them with all polygons drawn in
the last frame and output *the*difference* to screen. This eliminates
the need to erase your offscreen map and since two successive frames
are usually similar to each other, you just draw a fraction of what
you usually do. Although the overhead for collecting the polygons
is probably a bit more than drawing them, the subsequent elimination
of 90% that needs to be redrawn makes up for this. Also, if you just
output the difference, this eliminates the need to as this is included
into the algorithm.

Mhhh. On second thought, this doesn't work at all for a scrolling
background... But then, neither CYAC nor AC3D have moving background.

> I don't know enough about 3D graphics to know whether you could
> actually render even/odd scanlines or whether he's just splitting an
> off-screen drawing into two blits.

Well, I have some experience with 3D graphics and there are to
fundamental different approaches. On is called object-space, the
other scan-space (well, at least in german. They seem to translate
badly). In object space you calculate all surfaces of the objects
and project them on your (off)screen using normal projection methods.
To tune your animation you use object coherencies (you take
advantage of the fact that an object doesn't change much between
two frames). In this algorithm you can't render only for odd lines.
You have to render the whole scene and then transfer every other
line.

In scan space you take the inverted approach. For each pixel you
decide which surface is frontmost and set this pixel to the
appropriate color/texture. To tune this algorithm you can use
scan-line coherencies (the fact that two pixels in any direction
usually don't change much in color, both in x and y direction).
With scan-space, you *can* render every other line directly.

The third possibility is a combination of both methods. It's what
Juri's program does (as I suspect. I havn't seen a single line of
his code, but the performance of the demos he sent me leave no
other explanation). You use object space to pre-calculate all
objects (i.e. all vertices that define your surfaces), collect
them to polygons that are not drawn but *mathematically* compared
to the last frame, collect the difference to other polygons and
finally draw the new polygons (using scan coherencies). You
can draw directly to screen since you change so few things that
it seems instantaneous. Juri claims that his algorithm is a
bit faster than the one used in FA-18 (I think they use
a similar approach) and quite frankly, I believe every word
of it.

>
> Sean

OK, sorry to have held you up with this rather lengthy discussion
of some arcane and irrelevant topic, but I have spent a lot of
time investigating this and maybe someone can make some use out
of it. Have a nice day.


Cheers,
Christian

- -
Christian Franz                    *       Union Bank of Switzerland, CH
[e-mail]     <- at home ->               [phone]

---------------------------

>From Frank Manshande <[e-mail]>
Subject: FlattenMovieData bug???
Date: Mon, 13 Jun 1994 14:47:53 GMT
Organization: AND Software BV

Hi,

According to the Q/A in Develop 16 (page 130)...

"Since FlattenMovieData" will simply append to a data fork of
a file, you can pass it any data file and it will append the
movie data to that file. Quicktime doesn't care what's stored
before or after the movie data, as long as you don't reposition
the movie data within the data dile."

Well, if I try this, and append a movie using FlattenMovieData",
the first 8 bytes will be overwritten with 4 bytes and then 'mdat'.

Even if I pass the flag 'flattenAddMovieToDataFork' !

It seems like this is a bug! I don't want that data stored before
the movie overwritten. My solution now is to read the first 8
bytes, then FlattenMovieData one or more quicktimes movie files
and then restore the first 8 bytes. But I am not certain that
replacing those 8 bytes won't have any side effects. What I do
is store the "Movie" structure, using PutMovieIntoDataFork at
a specific offset.

My datafile looks like this:

- -------------------------------
| some data (other than movies) |
- -------------------------------
| flattened movie               |
- -------------------------------
| "Movie" structure             |
- -------------------------------
| flattened movie               |
- -------------------------------
| "Movie" structure             |
- -------------------------------
| flattened movie               |
- -------------------------------
| "Movie" structure             |
- -------------------------------

This works. But the first 8 bytes are overwritten in "some data".

Any info would be very much appreciated!

Frank Manshande
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Mon, 13 Jun 1994 18:05:25 GMT
Organization: The World Public Access UNIX, Brookline, MA

Frank Manshande <[e-mail]> writes:

>This works. But the first 8 bytes are overwritten in "some data".

What happens is that QT stores the info in a Bento-like atomic form. The
single-fork movie (flattened means "self-contained", not "single-fork").
must contain "atoms" in order for QT to properly navigate it. Atoms are
structured as follows:

    {
        long    atomSize;    //    includes atomSize+atomType
        OSType    atomType;
        ... atom specific data ...
    }

So for your multimovie file to work it needs to contain atom headers
before each movie data atom of the right size. It also needs an
atom header in front of your data to allow QT to traverse the movie.
This isn't a bug AFAIK; it seems Develop 16 was wrong in the general
case (you can't just append the movie data for single fork files). If
you control the file format, however, and you can add the atom header
yourself, then it is feasible to do what they say. Given this structure,
however, I'd avoid "restoring" the first 8 bytes as you were doing,
since it's bound to affect your ability to access the multiple movies...

Additionally, you might want to check out John Wang's article
in Develop 17 ("Somewhere in QuickTime"), since I seem to remember
there is a bug in FlattenMovieData in which the size field is not
properly set when using multiple movies, and a fix (BetterFlattenMovieData)
is discussed in it.

Hope this helps,

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From Frank Manshande <[e-mail]>
Date: Tue, 14 Jun 1994 06:51:11 GMT
Organization: AND Software BV

In article <[e-mail]> Ivan M CaveroBelaunde,
[e-mail] writes:
>If you control the file format, however, and you can add the atom header
>yourself, then it is feasible to do what they say. Given this structure,
>however, I'd avoid "restoring" the first 8 bytes as you were doing,
>since it's bound to affect your ability to access the multiple movies...

Well,

First of all thanks for your time!

I have written two small programs. One that adds a movie to ANY kind
of file, and displays the offset of the 'movie resource' using the
PutMovieIntoDataFork call. And another program that can play the movies
at the specified offsets. This does seem to work correctly.

The only side-effect I have encountered so far is that the file which
I added the movies to cannot be played by SimplePlayer. SimplePlayer
can play the first movie if I don't save and restore the first 8 bytes
of the file. But because I don't want to play the movies using a
general movie player, but only from my own program, this should not
be a problem.

The reason I have to restore the first 8 bytes of the file is that
the quicktime movies are added to a specific database file (the database
file is of proprietary format), and the database engine doesn't work
if the first 8 bytes are overwritten.

The reason why I don't just create two seperate files (one with the
database and one with all the quicktime movies) is that our customers
(and our company) only wants ONE file, which contains all the data.

Does anybody know if saving and restoring the first 8 bytes that
FlattenMovieData overwrites has any other side effects then not
allowing programs such as SimplePlayer to play a movie?

Thanks!

Frank Manshande
[e-mail]

+++++++++++++++++++++++++++

>From Peter Vanags <[e-mail]>
Date: 15 Jun 1994 20:43:47 GMT
Organization: UCB

In article <[e-mail]> Frank Manshande, [e-mail] writes:
>Does anybody know if saving and restoring the first 8 bytes that
>FlattenMovieData overwrites has any other side effects then not
>allowing programs such as SimplePlayer to play a movie?

Nope, not a problem. The only caveat is you MUST use
NewMoveFromDataFork() with the offset to the 'mdat' or 'moov' atom to
retrieve the movie, if the other data in the data fork is not stored in
"atom" form.

To be clean about using FlattenMovieData(), you should use the following
procedure:

- store the first 8 bytes of the data fork
- store the file's length
- append a dummy 'mdat' atom to the end of the data fork
- call FlattenMovieData()
- check the offset to the end of the movie data, which is now
  in the first 4 bytes of the data fork, compare to the length
  before FlattenMovieData() was called
  and update your dummy atom
- restore the first 8 bytes of the file's data fork

I talked with John Wang at MacDTS (author of the "Somewhere in QuickTime"
column in develop) quite a bit about this issue right before he published
the article.


Peter Vanags
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Wang)
Date: 16 Jun 1994 00:27:12 GMT
Organization: Apple Computer, Inc.

FYI.  The bug fix for the problem described in issue #17 of my article has
been added to QuickTime 2.0.  If you use my BetterFlattenMovie or
BetterFlattenMovieData routine, you will be all set since
BetterFlattenMovie only patches FlattenMovie when QuickTime 1.6.X or
earlier is used.

John

---------------------------

>From Jens Alfke <[e-mail]>
Subject: Here's how to get OpenDoc
Date: Wed, 15 Jun 1994 23:30:31 GMT
Organization: Apple Computer

I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas,
to get the true facts about OpenDoc seeding. Here's the scoop.

* The current (a6) version of OpenDoc is _not_ going to be distributed more
widely than to the WWDC attendees. They decided against a blanket mailing to
all registered developers because, as Mark put it, "You only get one chance
to make a good first impression". The a6 build is still a bit flaky, requires
MPW, and doesn't come with much in the way of documentation. Their fear was
that, if everybody got it, many would play with it a little, run into
problems, and not look at it again later when things are more polished.

* The beta seed _is_ going to be distributed widely. It'll be on the
developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get
a number of OpenDoc articles in that issue of 'develop'. (Note that anyone
can order single issues of 'develop' from APDA for $10.) This will probably
be in September given the lead time involved in pressing CDs. By that time
the code will be more stable, you'll be able to build with CodeWarrior (hope
hope hope), and there will be at least draft versions of the official
documentation for both OpenDoc and the framework.

* But! If you're interested in getting started with OpenDoc _now_ (and how
can I blame you?) you can send mail to [e-mail] and get a
CD with version a6 in return for filling out a short form.

* Feel free to post OpenDoc questions here; I'll try to answer them. There is
an OpenDoc mailing list; send mail to <[e-mail]> with body
"subscribe opendoc-interest" to subscribe. There is also a discussion board
on AppleLink somewhere.

I hope this answers your questions. Sorry about any misinformation I've
posted in the past ...

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Browne)
Date: Thu, 16 Jun 1994 16:35:00 GMT
Organization: Drexel University

Jens Alfke ([e-mail]) wrote:
: I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas,
: to get the true facts about OpenDoc seeding. Here's the scoop.

: * The beta seed _is_ going to be distributed widely. It'll be on the
: developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get

Thanks, Jens

Is there any problem with lending it to Metrowerks for shipping on the
DR4 CD, which roughly comes out at the same time?
(Not that I'm trying to save a couple of bucks or anything... :-) )

Chuck



+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 16 Jun 1994 22:55:44 GMT
Organization: Apple Computer

Chuck Browne, [e-mail] writes:
> Is there any problem with lending it to Metrowerks for shipping on the
> DR4 CD, which roughly comes out at the same time?

I think Mark wants people to go directly to Apple to obtain it. He wants to
keep tabs on how many people have it and who they are (in case we need to
send out any mass mailings, or sell your names and addresses to The Sharper
Image :)

> (Not that I'm trying to save a couple of bucks or anything... :-) )

I don't think we're charging anything for the OpenDoc seed.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Browne)
Date: Fri, 17 Jun 1994 00:58:43 GMT
Organization: Drexel University

Jens Alfke ([e-mail]) wrote:
: Chuck Browne, [e-mail] writes:
: > Is there any problem with lending it to Metrowerks for shipping on the
: > DR4 CD, which roughly comes out at the same time?

: I think Mark wants people to go directly to Apple to obtain it. He wants to
: keep tabs on how many people have it and who they are (in case we need to
: send out any mass mailings, or sell your names and addresses to The Sharper
: Image :)

: > (Not that I'm trying to save a couple of bucks or anything... :-) )

: I don't think we're charging anything for the OpenDoc seed.

I meant the $10 for develop, but what you say is good to hear.
(Not that I need OpenDoc or anything, I'm just curious about it and
what it will mean to software in the next couple of years...
maybe I'll try it out, if I manage to get my PhD on schedule..)

Thanks,
Chuck


: --Jens Alfke
:   jens_alfke@powertalk              Rebel girl, rebel girl,
:             .apple.com              Rebel girl you are the queen of my world

---------------------------

>From [e-mail] (Yves Belanger)
Subject: How to know the cursor is into a polygon?
Date: Tue, 14 Jun 1994 18:09:32 GMT
Organization: Universite Laval, Ste-Foy (Quebec), Canada

Hello,

I am writing an application where districts are drawn on a geographic
map. Districts are made with many points, like a polygon in MacDraw.
Each point is given a longitude and a latitude. I have functions that
translate back and forth these coordinates into screen coordinates.

My problem is how to determine that a user has clicked inside one of
those polygon or the click was outside them all? If the solution could
work with longitude and latitude, that would be greater, since less
computing would be involved. Thank you.

S. Beaudry

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Tue, 14 Jun 1994 22:49:07 GMT
Organization: The Information Workshop

In article <[e-mail]> Yves Belanger,
[e-mail] writes:

> I am writing an application where districts are drawn on a geographic
> map. Districts are made with many points, like a polygon in MacDraw.
> Each point is given a longitude and a latitude. I have functions that
> translate back and forth these coordinates into screen coordinates.

The most common approach is to take advantage of the Macintosh's built-in
region capabilities. They are incredibly powerful, and very easy to use.

You can easily take any polygon and create the equivalent region from it,
which is kept in a RegionHandle.

Keep a list of these RegionHandles handy, one for each district, and when
the user clicks, take the location of the click and then in a loop use
the PtInRgn() toolbox call to test whether that point is within each of
the regions.  When the result is true, bingo.

If there are overlapping regions, be sure they are set up and tested in
front to back order.

That's all there is to it, unless I misunderstood your situation.

I forget the exact calls to make a region from a polygon, but the whole
process is exceedingly simple.

This is the only approach I know of, really.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 14 Jun 1994 21:09:23 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Yves
Belanger) wrote:

> Hello,
>
> I am writing an application where districts are drawn on a geographic
> map. Districts are made with many points, like a polygon in MacDraw.
> Each point is given a longitude and a latitude. I have functions that
> translate back and forth these coordinates into screen coordinates.
>
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all? If the solution could
> work with longitude and latitude, that would be greater, since less
> computing would be involved. Thank you.

My approach would be based on creating a QD region which covers the same
"territory" as the polygon, and using the provided PtInRgn call against the
region.  Only if that were not "fast enough" would I probe further.

Or...better...switch to QuickDraw GX, where you're likely to be working
with a polygon shape, and you can easily hit-test that (or any other
shape).  That may put things a little more into the future than you want,
though.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 15 Jun 1994 22:21:34 GMT
Organization: Apple Computer

In article <[e-mail]> Yves Belanger,
[e-mail] writes:
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all?

As has been said, the easiest solution is to create a region of the same
shape as the polygon, then call PtInRegion. This does have the drawback that
regions containing diagonal lines eat up lots of memory. (Think of the
boundary of the region as a polygon, including little stairsteps at pixel
edges on diagonal lines. The region then occupies about two to four bytes per
vertex of that polygon.) Unfortunately, regions larger than 64kbytes will
crash QuickDraw. This shouldn't be a problem unless your polygons are very
large or complex.

To create a region from a polygon:
* Call OpenRgn
* MoveTo the first point in the polygon, LineTo each succeeding point. Make
sure to end with a LineTo back to the first point.
* Call CloseRgn.

Your other alternative is to use a real "point in polygon" test. You could
either be the four millionth person this month to ask about this on
comp.graphics.algorithms, or you could get a standard computer graphics
textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam
et al. There may also be source code available by ftp, but I have no idea
where.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 16 Jun 1994 09:28:11 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> Jens Alfke <[e-mail]> writes:
>In article <[e-mail]> Yves Belanger,
>[e-mail] writes:
>> My problem is how to determine that a user has clicked inside one of
>> those polygon or the click was outside them all?
>
>As has been said, the easiest solution is to create a region of the same
>shape as the polygon, then call PtInRegion. This does have the drawback that
>regions containing diagonal lines eat up lots of memory. (Think of the
>boundary of the region as a polygon, including little stairsteps at pixel
>edges on diagonal lines. The region then occupies about two to four bytes per
>vertex of that polygon.) Unfortunately, regions larger than 64kbytes will
>crash QuickDraw. This shouldn't be a problem unless your polygons are very
>large or complex.
>
>To create a region from a polygon:
>* Call OpenRgn
>* MoveTo the first point in the polygon, LineTo each succeeding point. Make
>sure to end with a LineTo back to the first point.
>* Call CloseRgn.
>
>Your other alternative is to use a real "point in polygon" test. You could
>either be the four millionth person this month to ask about this on
>comp.graphics.algorithms, or you could get a standard computer graphics
>textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam
>et al. There may also be source code available by ftp, but I have no idea
>where.



>From the UMPG Vol II

Subject: Re: Point in Polygon routine needed
From: [e-mail] (David Fry)

In article <8fxkxAO00WB7M=[e-mail]> Andrew Lewis Tepper <[e-mail]> writes:
>I don't know if this routine is "standard", I just came up with it recently:
>
>For a polygon of points p1...pn, and a point P, make a table as follows:
>
>T(1)= angle from p1 to P to p2
>T(2)= angle from p2 to P to p3
>...
>T(n)= angle from pn to P to p1
>
>express all angles as: -PI < angle < PI.
>
>Add all entries in the table. If the sum = 0, the point is outside. If
>the sum is +/- PI, the point is inside. If the point is +/- xPI, you
>have a strange polygon. If ANY angle was = +/-PI, the point is on the
>border.
>
>Does anyone know if this is considered a good (known?) algorithm? It
>took a long time to come up with!

You have the essence of the "good," standard algorithm, but if you're
working with thousands of polygons, those floating point calculations
will be too slow and will probably lead to round-off error at some
point.  Round-off error is a huge pain in computational geometry
problems.  The hard part is finding ways to avoid it.

The trick is that you don't need to know the angle between the lines,
you just need to know its sign, called the *circulation*.   For every
line AB in the polygon, form the triangle PAB and you want to know
does it lie inside the polygon or not.  That is, if you were riding a
bike counterclockwise around the boundary of the polygon, would P
lie on your left or your right when you crossed AB?  You can find this
by calculating PA x PB = (A.x-P.x)*(B.y-P.y) - (A.y-P.y)*(B.x-P.x).
The circulation (the sign of PA x PB) can be found without doing a
multiplication in many cases, but this is good enough.  Remember,
we've oriented the polygon so that you come to A before coming to B as
your traverse its boundary.

Then the algorithm is:

In = 0
foreach edge AB in the polygon
    if A.y < P.y and B.y >= P.y and PA x PB > 0
        In = In + 1
    if A.y >= P.y and B.y < P.y and PA x PB < 0
        In = In - 1

Then if In = 1, P is inside the polygon, and is outside if I = 0.
This doesn't handle the case where P lies on some edge AB of the
polygon.


David Fry                                  [e-mail]
Division of Applied Sciences               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138


- ----------
end of artile


Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From Rick Wong <[e-mail]>
Date: 16 Jun 1994 17:59:54 GMT
Organization: Stanford University

In article <[e-mail]> Yves Belanger,
[e-mail] writes:
> My problem is how to determine that a user has clicked inside one of
> those polygon or the click was outside them all?

One approach is to create an offscreen bitmap with its origin set
up so that the bitmap is centered around the click locaction.  The
bitmap doesn't have to be very big at all, just enough for your hit
tolerance.  For each polygon you want to test, clear the bitmap,
then draw the polygon into it (if you want to see if the point is
inside the polygon, you should draw it with a black fill pattern).
You can then examine the individual bits around the click location
to see if any are set.

Of course, such "cleverness" is unnecessary under QuickDraw GX....

--Rick Wong

---------------------------

>From [e-mail] (Gary Kacmarcik)
Subject: PowerPC load-store (was Re: Fast full screen scrolling: impossible?)
Date: 15 Jun 1994 15:23:53 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] writes:

> And finally, what happened to the load/store multiple instructions that are
> (I assume?) faster on the 601, but will probably be slower "in future
> implementations?"

the load/store multiple instructions are not faster than a series of loads
and stores (except perhaps if there are stalls from the instruction cache).
they take 1 cycle per load or store.

these instructions are present to make saving and restoring registers
(GPRs only) to the stack a little bit easier.  that's really the only benefit
to them.

many of the PowerPC architects do not like these instructions because they
do not fit the RISC model very well, thus they complicate the processor
implementation.  don't expect IBM/Motorola to invest much time on these
instructions.  witness the lack of equivalent instructions for floating-
point registers or for 64-bit GPRs.

these instructions will become slower when they decide to eliminate them
and handle them via trap-and-emulate. (hey, at least they're telling you
all this up front)

-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Wed, 15 Jun 1994 20:34:44 GMT
Organization: Adobe Systems Incorporated

Gary Kacmarcik writes
> the load/store multiple instructions are not faster than a series of loads
> and stores (except perhaps if there are stalls from the instruction
cache).
> they take 1 cycle per load or store.

Which will happen relatively often on the 601. (For example anytime you save
8 or more registers, its guaranteed to happen.)

> these instructions are present to make saving and restoring registers
> (GPRs only) to the stack a little bit easier.  that's really the only
benefit
> to them.

They improve code density somewhat. Given the size of native apps that's a
concern.

> many of the PowerPC architects do not like these instructions because they
> do not fit the RISC model very well, thus they complicate the processor
> implementation.  don't expect IBM/Motorola to invest much time on these
> instructions.  witness the lack of equivalent instructions for floating-
> point registers or for 64-bit GPRs.

Bottom line: the architecture would be better without load/store multiple.
However since the architects could not reach agreement to remove these
instructions, the implementors should support them. As it stands now, some
implementors will makes these instructions competitive and some won't.
Applications developers will be stuck with a choice which way to go. For
load/store multiple, this doesn't bother me that much. (One might take a
minor speed hit to win on code space most places anyway.) However the manual
says similar things about load/store update instructions vs. using a
load/store and an add instruction. This causes a much bigger performance
tradeoff right in the middle of your inner loops. A PowerPC implementation
where the two instruction sequence is faster than an update form instruction
would be braindead.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
`Wait a second! This is just an octahedron suspended in blue liquid.' - JT

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 16 Jun 1994 18:34:53 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (Zalman Stern) writes:
>
> Gary Kacmarcik writes
> > these instructions are present to make saving and restoring registers
> > (GPRs only) to the stack a little bit easier.  that's really the only
> > benefit to them.
>
> They improve code density somewhat. Given the size of native apps that's a
> concern.

but they don't affect code density all that much.  the recommended way
doing the load/store sequence of instructions is to have a series of
loads (or stores) somewhere in the app or OS like

   lwz    r13,0(r0)
   lwz    r14,4(r0)
   ...
   lwz    r31,68(r0)
   bcctr

(or something like that - i believe that the standard save/restore glue
does a few other things, but i don't have the exact sequence handy).

then a function that wants to save a bunch of registers just calculates
the address of where the first register should be saved and branches to
appropriate lwz instruction.  you have to do this anyway for floating-
point and 64-bit reg's, so it's not a big deal.

the end result is that if it's done this way, it won't have a big impact
on code density.  performance is basically to same too, since the branches
(both of which are unconditional) are "free" and the glue code may
already be in the i-cache (from previous functions).

-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Fri, 17 Jun 1994 04:23:38 +1200 (NZST)
Organization: (none)

[e-mail] (Gary Kacmarcik) writes:
> many of the PowerPC architects do not like these instructions because they
> do not fit the RISC model very well, thus they complicate the processor
> implementation.  don't expect IBM/Motorola to invest much time on these
> instructions.  witness the lack of equivalent instructions for floating-
> point registers or for 64-bit GPRs.
>
> these instructions will become slower when they decide to eliminate them
> and handle them via trap-and-emulate. (hey, at least they're telling you
> all this up front)

That won't be too bad -- everyone sees it coming, and coming (fairly) soon,
and if you're saving a number of registers the speed hit won't be *that*
horrible (but horrible enough), and most people don't use it inside of
tight loops, and it's no faster than the alternative anyway.

The really, *really* horrible one will come when the "load with update"
and "store with update" instructions get the trap-and-emulate treatment.

For the non PPC-savvy folk, those instructions get used to implement
the C constructs *++p and *--p (and *p++ and *p-- with a smart optomising
compiler that can transform your code).

They're used a *lot*, they're a big speed win on the 601 (less on the
603 and 604 if you don't mind tying up two units for a load and an addi
in parallel becasue you've got nothing better to do with them), and they
occur in speed-critical inner loops.

-- Bruce

---------------------------

>From [e-mail] (Eric A Fisch)
Subject: Q: Default button & Return key in Modeless Dialog
Date: 16 Jun 1994 18:56:00 GMT
Organization: Texas A&M Computer Science Department, College Station, TX

I am working with modeless dialogs and am quite pleased with the
results. I am having a problem defining a default button and making
the return (or enter) key activate it. Right now, when the return key
is pressed it is passed into the active editable text field. I do have
the OK button at item number 1, but I am clearly missing something. Any
thoughts?


Thanks,
Eric Fisch
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eddy J. Gurney)
Date: Thu, 16 Jun 1994 20:01:29 GMT
Organization: Hewlett-Packard VCD

Eric A Fisch ([e-mail]) wrote:
>I am working with modeless dialogs and am quite pleased with the
>results. I am having a problem defining a default button and making
>the return (or enter) key activate it. Right now, when the return key
>is pressed it is passed into the active editable text field. I do have
>the OK button at item number 1, but I am clearly missing something. Any
>thoughts?

Yes. After calling IsDialogEvent() from your event loop and determining
that this is an event for an open modeless dialog, you need to
"pre-process" the event before passing it on to DialogSelect() and check
for a "keyDown" or "autoKey" event when theEvent.message & charCodeMask
is equal to the Enter or Return key and process it appropriately... being
sure to NOT pass the event on to DialogSelect() afterwards.

You need to do a similar thing anyway to catch Command-key equivalents,
which DialogSelect() also just "pushes" through to TEKey...

--
Eddy J. Gurney N8FPW   Hewlett-Packard Company, Vancouver (USA!) Division
[e-mail]                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak

+++++++++++++++++++++++++++

>From [e-mail] (Paul DuBois)
Date: 16 Jun 1994 15:46:39 -0500
Organization: Castra Parvulorum

>From article <2tq780$[e-mail]>, by [e-mail] (Eric A Fisch):
> I am working with modeless dialogs and am quite pleased with the
> results. I am having a problem defining a default button and making
> the return (or enter) key activate it. Right now, when the return key
> is pressed it is passed into the active editable text field. I do have
> the OK button at item number 1, but I am clearly missing something. Any
> thoughts?

You have to handle it yourself in a modeless dialog.
--
Paul DuBois
[e-mail]

---------------------------

>From [e-mail] (jaime apablaza)
Subject: Questions about Tmon?
Date: Wed, 01 Jun 1994 03:19:37 GMT
Organization: University of Regina

How much does Tmon Pro cost and where can I order it from?  I read in the
faq that Tmon has a rather steep learning curve so I was wondering is
that because the manual is rather cryptic.  If so are there third party
books on using Tmon?  Email preferred.


+++++++++++++++++++++++++++

>From [e-mail] (Joseph Hall)
Date: Wed, 1 Jun 1994 05:42:03 GMT
Organization: Motorola Inc., Satellite Communications

Seems it was [e-mail] (jaime apablaza) who said:
>How much does Tmon Pro cost and where can I order it from?  I read in the
>faq that Tmon has a rather steep learning curve so I was wondering is
>that because the manual is rather cryptic.  If so are there third party
>books on using Tmon?  Email preferred.

I'm not aware of any books on TMON (other than the fairly good documentation
that comes with it), but at least TMON seems to have a future now.  For a
while it looked as if it had been dropped on the floor and left for dead.

The current trend is STRONGLY toward Jasik's The Debugger, though.
Obviously there is no TMON for PowerPC at this time.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Paul F. Snively)
Date: 1 Jun 1994 14:26:07 GMT
Organization: tumbolia.com

In article <[e-mail]>
[e-mail] (jaime apablaza) writes:

> How much does Tmon Pro cost and where can I order it from?  I read in the
> faq that Tmon has a rather steep learning curve so I was wondering is
> that because the manual is rather cryptic.  If so are there third party
> books on using Tmon?  Email preferred.

I would mail, but others might want to read this, too...

TMON Pro does have a significant learning curve, as does probably any
reasonably capable object-level debugger on the Mac.  The Mac is a
complex beast itself; to create a debugger that can interact with
heaps, resources, code, registers, etc. is difficult (says a guy who
used to work at ICOM Simulations, Inc.)

Having said that, here are my brief pointers for happiness in TMON Pro:

1) Whenever you have a TMON Pro window open, note the little square box
in
   the upper right corner.  It looks like a zoom box, and in a sense,
it is:
   it will expand the window to show a variety of hidden (ugh) options
for
   use in that window.

2) Learn--and I mean _really_ learn--TMON Pro's expression syntax.
Easily
   90% of the cool things that you can do with TMON involve non-trivial
use
   of expressions.  For example, TMON Pro's "Stack Crawl" window is
just a
   Memory window with a moderately hairy expression used to crawl up
the
   stack.  There's an even hairier expression used to create a Memory
window
   that gives the names of all of the windows in the current world
(hairy to
   do because the titleHandle is at different offsets in b&w vs. color
   windows).  In particular, make sure that you fully understand
delayed vs.
   immediate evaluation.

3) Remember that TMON Pro does, in fact, have a command line.
Command-space
   will open it.  You may think, "but I hate command lines!"  So do I,
but
   it's the only way to do certain things in TMON Pro, e.g. type:
   "Step 4*LongPointer != F*LongPointer" (that is, step until the value
at
   LongPointer changes).

Like many old-hand TMON/TMON Pro users, I'm delighted to know that TMON
Pro for the PowerMac is forthcoming.

- ---------------------------------------------------------------------
Paul F. Snively          "Just because you're paranoid, it doesn't mean
[e-mail]    that there's no one out to get you."

+++++++++++++++++++++++++++

>From [e-mail] (David Shayer)
Date: Wed, 1 Jun 1994 18:21:37 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

: > How much does Tmon Pro cost and where can I order it from?  I read in the
: > faq that Tmon has a rather steep learning curve so I was wondering is
: > that because the manual is rather cryptic.  If so are there third party
: > books on using Tmon?  Email preferred.

TMON is a great low level debugger, I don't think its any harder to use
than Macsbug, and it can certainly be easier to learn than Jasik.
It comes with 2 manuals, a reference manual and a tutorial.  I simply
read the tutorial all the way thru, and did all the examples.  It took
about a week of working every evening.  At the end, I was a TMON master.
(Well ok, I'm pretty competent with TMON :-)

There are no books I know of that explain how to use TMON.  However,
like all low level debuggers, if you don't know what's going on in
the Mac's guts, you won't know what you're looking at.  I highly
recommend Scott Knaster's book, How to Write Mac Software.  It actually
does have some examples in TMON, but in TMON 2.8, which is very old.

TMON 3.0 is available from APDA (800-282-2732) for $250.
It suppoessedly has a few quirks on the PowerPC.  Its been bought
by a new company, which is doing a PPC upgrade, so hopefully we'll
see a new version of TMON soon.

+------------------------------------------------------------------------+
|David Shayer                                  [phone]            |
|Sentient Software / Symantec                  [e-mail]|
|"They're not the best at what they do,        Applelink: SHAYER         |
| but they're the only ones who do what they do."                        |
+------------------------------------------------------------------------+


+++++++++++++++++++++++++++

>From [e-mail] (Robert Schwalbe)
Date: Sat, 11 Jun 1994 09:53:24 -0800
Organization: IN SOFTWARE

In article <[e-mail]>, [e-mail] (David
Shayer) wrote:

> TMON 3.0 is available from APDA (800-282-2732) for $250.
> It suppoessedly has a few quirks on the PowerPC.  Its been bought
> by a new company, which is doing a PPC upgrade, so hopefully we'll
> see a new version of TMON soon.

What is the name of this 'new' company, and how would we get in
contact with them?

======================================================================
Robert Schwalbe                          INET:  [e-mail]
IN SOFTWARE                              Voice: 619.743.7502
2403 Conway Drive                        Fax:   [phone]
Escondido, CA 92026

+++++++++++++++++++++++++++

>From [e-mail] (David Shayer)
Date: Wed, 15 Jun 1994 05:03:14 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Robert Schwalbe ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (David
: Shayer) wrote:

: > TMON 3.0 is available from APDA (800-282-2732) for $250.
: > It suppoessedly has a few quirks on the PowerPC.  Its been bought
: > by a new company, which is doing a PPC upgrade, so hopefully we'll
: > see a new version of TMON soon.

: What is the name of this 'new' company, and how would we get in
: contact with them?

The new "company" is really one guy, named Allan Foster.  You
can reach him at [e-mail].

David


---------------------------

>From [e-mail] (Carl B. Constantine)
Subject: Saving PICT files - Here's CODE!!
Date: Thu, 16 Jun 1994 07:10:55 -0700
Organization: Ministry of Environment, Lands & Parks

Here is some code that works for saving PICT files.  This code was
developed by a friend of mine, I'm not the author.

Here you go.

OK, I have working code for writing a PICT file from a mac Picture.
The trick is to write the fields of the Picture in the proper order.
Write 512 zeros, for conformity with old PICT files & MacDraw.
Then write the picture size, the picture rect, and finally the picture
opcodes.


PicHandle macPicture;
static Point SFPwhere = { 150, 150 };
static SFReply reply;

void MakePICTFile ()
{
    OSErr iErr;
    int iFileRef;
    CQDProcs myProcs;
    int longZero, i;
    long longCount = 1;
    Rect pFrame;
    PicHandle newPICTHand;
    short globalRef;
    Rect temp;
    int tempSize;

    SFPutFile ( SFPwhere, "\pSave PICT Plot as:","\pSaved PICT
Plot",NULL,&reply);

    if (reply.good)
    {


        PleaseWait ();                            /* change to watch cursor */
        ExerciseOffScreen ();                    /* draw pict in off-screen bitmap */

        iErr = Create ( reply.fName, reply.vRefNum, 'MKGW', 'PICT' );
                                                /* create file */
        if (iErr != 0)
        {
            puts("Error - could not create file\n");
            return;
        }

        iErr = FSOpen ( reply.fName, reply.vRefNum, &globalRef );
                                                /* open file */

        for ( i = 1; i<= 512; i++)                /* write 512 zeros for conformity to
standard */
            FSWrite (globalRef, &longCount, 0);


        longCount = 2;                            /* write picture size */
        tempSize = (*macPicture)->picSize;
        FSWrite (globalRef, &longCount, &tempSize);

        longCount = 8;                            /* write picture rect */
        temp = (*macPicture)->picFrame;
        FSWrite (globalRef, &longCount, &temp);
                                                /* write picture */
        longCount = GetHandleSize ((Handle) macPicture);
        FSWrite (globalRef, &longCount, (Ptr) (*macPicture)+10);
                                                /* picture starts 10 bytes from beginning address */

        FSClose (globalRef);
    }

}


Good luck!

--
=========================================================================
Carl B. Constantine                      B.C. Environment, Lands & Parks
End-User Support Analyst                 [e-mail]
   PGP Key available if you finger: [e-mail]

---------------------------

>From [e-mail] (Nick Hodulik)
Subject: Scroll Bars in DLOG?
Date: 6 Jun 1994 03:52:22 GMT
Organization: Norden 1 Communications

How does one make scroll bars work in a DLOG resource? I know it has something
to do with the CNTL resource, but I can't figure it out. Please help me!

Nick

--
*-----------------------*------------------------------------*---------------*
|[e-mail]   | "This train                        |   *------*    |
|Norden1 Communications |         is bound                   |    \ GO /     |
|Nick Hodulik           |              for glory..."         |    TITANS!    |
|Toledo, OH             |                    -Indigo Girls   |      \/       |      \/       |
*-----------------------*------------------------------------*---------------*

+++++++++++++++++++++++++++

>From Alex Kac <[e-mail]>
Date: Sat, 18 Jun 94 12:57:50 -0500
Organization: Delphi ([e-mail] email, 800-695-4005 voice)

Nick Hodulik <[e-mail]> writes:

>How does one make scroll bars work in a DLOG resource? I know it has something
>to do with the CNTL resource, but I can't figure it out. Please help me!
>
>Nick

Ok...here is some ol PASCAL source for you (easier to read)
FUNCTION NewDlogFilter (theDialog: DialogPtr;
       VAR theEvent: EventRecord;
       VAR itemhit: integer): boolean;

first, you need to use a ModalDialogFilter (if you're using a modaldialog)
 BEGIN
  setport(theDialog);
  IF (theEvent.what = update) AND (WindowPtr(theevent.message) <> theDialog) &
(WindowPeek(WindowPtr(theEvent.message))^.windowkind = dlog) THEN
   UpdtDialog(theDialog, (WindowPeek(WindowPtr(theEvent.message))^.updateRGN))
  ELSE IF (theEvent.what = activate) AND (DialogPtr(theEvent.message) <>
theDialog) THEN
{Deactivate any window behind....}
  ELSE
   CASE theEvent.what OF
...do key stuff here....
    M_Down:
     BEGIN
      hitPt := theEVENT.where;
      GlobalToLocal(hitPt);
      Ahit := FindControl(hitPt, theDialog, hitControl);
      IF NOT (hitControl = NIL) THEN
       BEGIN
       dhit := FindDitem(theDialog, hitpt) + 1;
       GetDitem(theDialog, dhit, itemtype, itemhandle, itemrect);
{here I could have put a contrlAction in each of the 3 controls before I
started the Dialog, but thought this was the best way}
       CASE Ahit OF
       inButton:
       BEGIN
       CASE itemtype OF
       4..6:
       Ahit := TrackControl(hitControl, hitpt, NIL);
       7:
       Ahit := TrackControl(hitCOntrol, hitpt, Pointer(-1));    {since this is a
button, it can only be a PopUpMenu...}
       OTHERWISE
       ;
       END;
       CASE dhit OF
...buttons and other stuff here....
       inUpButton:
       IF NOT (TrackControl(hitControl, hitpt, @UpButtonProc) = 0) THEN
       BEGIN
       NewDlogFilter := true;
       itemhit := dhit;
       END;

       inDownButton:
       IF NOT (TrackControl(hitControl, hitpt, @DownButtonProc) = 0) THEN
       BEGIN
       NewDlogFilter := true;
       itemhit := dhit;
       END;

       inThumb:
       IF NOT (TrackControl(hitControl, hitpt, NIL) = 0) THEN
       BEGIN
       ChangeBut(hitcontrol, theDialog);
       NewDlogFilter := true;
       itemhit := dhit;
       END;

       OTHERWISE
       ;
       END;
       END;
     END;        {end of MDown}



By!

---------------------------

>From [e-mail] (Matt Burch)
Subject: Why should't you move baseAddrs?
Date: 15 Jun 1994 18:19:52 -0500
Organization: Kansas State University

Forgive me for sounding obtuse, but what excactly is wrong with
moving around baseAddrs? What's to prevent you from creating, say,
a GWorld or other offscreen pixmap with the same dimensions and
depth as the screen, and then setting the screen's baseAddr to
the baseAddr of the buffer when you want to draw a frame, instead
of blasting it into video memory? Am I missing something here?
Probably.

- Matt Burch


+++++++++++++++++++++++++++

>From [e-mail] (Kevin Bell)
Date: Wed, 15 Jun 1994 23:30:38 -0600
Organization: The University of Texas at Austin, Austin, Texas

In article <2to2ao$[e-mail]>, [e-mail] (Matt Burch)
wrote:

> Forgive me for sounding obtuse, but what excactly is wrong with
> moving around baseAddrs? What's to prevent you from creating, say,
> a GWorld or other offscreen pixmap with the same dimensions and
> depth as the screen, and then setting the screen's baseAddr to
> the baseAddr of the buffer when you want to draw a frame, instead
> of blasting it into video memory? Am I missing something here?
> Probably.
>
> - Matt Burch

The reason is that PixMaps are a QuickDraw software data structure, which
has little relation to the underlying video hardware. So if you change the
screen's baseAddr, QuickDraw commands will draw to the new port (if it
doesn't crash, I've never tried this), but the video hardware will continue
to fetch screen data from the old address.

--
Kevin Bell
[e-mail]

---------------------------

>From [e-mail] (Shawn V. Hernan)
Subject: cntl-opt-esc
Date: 14 Jun 1994 00:19:12 GMT
Organization: The University of Pittsburgh

Greetings all,

   Once again, I turn to the wisdom of the net...

   Is there any way to programatically intercept the cnt-alt-esc
keysequence? You know, the one that asks you if you really want to
force such and such to quit. I thought this was an AppleEvent, but
apparantly not....


Is this a FAQ? Do I have to resort to testing for that in my keyDown
events?

Any help is deeply appreciated,

Thanks,
Shawn



Shawn Valentine Hernan       |Is the War on Drugs worth it?
The University of Pittsburgh |Why does the government want your guns?
[e-mail]           |Does RICO ring a bell?
412-624-6425                 |Did you vote in the last election?

+++++++++++++++++++++++++++

>From Steve Maller <[e-mail]>
Date: 14 Jun 1994 19:39:26 GMT
Organization: General Magic

In article <2tit20$[e-mail]> Shawn V. Hernan,
[e-mail] writes:
>   Is there any way to programatically intercept the cnt-alt-esc
>keysequence? You know, the one that asks you if you really want to
>force such and such to quit. I thought this was an AppleEvent, but
>apparantly not....
>
>Is this a FAQ? Do I have to resort to testing for that in my keyDown
>events?

No dice. It's a pretty low level system patch (to PostEvent, I think)
so you'd have to patch PostEvent yourself and filter it out.
- ---------------------------------------------------------------
Steve Maller
Husband & Father
General Magic, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 14 Jun 1994 15:33:11 -0700
Organization: SRI International, Menlo Park, CA

In article <2tl11e$[e-mail]> Steve Maller <[e-mail]> writes:
>In article <2tit20$[e-mail]> Shawn V. Hernan,
>[e-mail] writes:
>>   Is there any way to programatically intercept the cnt-alt-esc
>>keysequence? You know, the one that asks you if you really want to
>>force such and such to quit. I thought this was an AppleEvent, but
>>apparantly not....
>>
>>Is this a FAQ? Do I have to resort to testing for that in my keyDown
>>events?

Here you go from the up and coming UMPG volume II.
(yes I'm actually working on it)




Subject: No Option Escape code
From: Manuel Veloso <[e-mail]>
Distribution: world

Someone a while back wanted code for killing off Force-Quit. Well, here's
one I found on CIS (I think) a few weeks ago. It works(!). It's in MPW
assembly, but 95% of it is the generic init install/patch. For anyone
doing
standalone systems (kiosks), well, you know...

;    NoEscape.a

                include    'Traps.a'

                machine    mc68000
                case    obj

INITEntry        proc    export

                lea        EndPatch,a0
                lea        StartPatch,a1
                sub.l    a1,a0
                move.l    a0,d0
                move.l    a0,d3
                _NewPtr sys
                move.l    a0,d4
                beq.s    NoPatch

                move.l    a0,a1
                lea        StartPatch,a0
                move.l    d3,d0
                _BlockMove

                move.w    #$a9c9,d0
                _GetTrapAddress newTool
                lea        RealSysError,a1
                move.l    a0,(a1)
                move.w    #$a9c9,d0
                move.l    d4,a0
                _SetTrapAddress newTool
NoPatch
                rts

StartPatch        cmpi.w    #$4e22,d0
                beq.s    NoThanks
                move.l    RealSysError,-(sp)
NoThanks
                rts

RealSysError    ds.l    1

EndPatch        equ        *

                endp

                end
--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Greg Marriott)
Date: Wed, 15 Jun 1994 06:21:07 -0800
Organization: General Magic, Inc.

Steve Maller <[e-mail]> wrote:
> [e-mail] writes:
> >   Is there any way to programatically intercept the cnt-alt-esc
> >keysequence?>
> No dice. It's a pretty low level system patch (to PostEvent, I think)
> so you'd have to patch PostEvent yourself and filter it out.

Or you could patch SysError and intercept the dialog just before it comes
up, pretending the user hit cancel.

--
Greg Marriott
Just Some Guy
General Magic, Inc.

Disclaimer: My opinions are not necessarily the same as General Magic's.
            (can a company even HAVE an opinion?)

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 15 Jun 1994 16:14:42 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>
Greg Marriott, [e-mail] writes:
>Steve Maller <[e-mail]> wrote:
>> [e-mail] writes:
>> >   Is there any way to programatically intercept the cnt-alt-esc
>> >keysequence?>
>> No dice. It's a pretty low level system patch (to PostEvent, I think)
>> so you'd have to patch PostEvent yourself and filter it out.
>
>Or you could patch SysError and intercept the dialog just before it comes
>up, pretending the user hit cancel.

SysError(20002) is how force-quit happens.

As Greg said, just patch it to just RTS when the error code is 20002,
otherwise call through.

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

>From [e-mail] (Fred Dushin)
Subject: scroll bars in modal dialogs
Date: Thu, 16 Jun 1994 15:44:22 GMT
Organization: Syracuse University, CIS Dept.

>From what I gather from Inside Mac (old volume I and
Toolbox Essentials), I need to handle mouseDown events
in scroll bars in modal dialogs with a filter proc.  I.e.,
ModalDialog does not return the part code for the control,
just the controlID.

Is that so?  If so, does someone have a sample filter procedure
that handles scroll bars I can scavange from?  Braaa.


Fred Dushin
Syracuse, NY

+++++++++++++++++++++++++++

>From Here@There (Someone)
Date: 17 Jun 1994 16:47:46 GMT
Organization: Large Fuzzy Room

In article <[e-mail]>,
[e-mail] (Fred Dushin) wrote:
> Is that so?  If so, does someone have a sample filter procedure
> that handles scroll bars I can scavange from?  Braaa.
DialogBits 2.0.1 does this, it's on the DevCD and the ftp site.  Here's the
relevant code from the filter proc that tracks the scroll
control.............
// cut and paste into MPW to view right
// inside your filter proc
GetDItem(inputDialog, kScrollControlItem, &tempItem, &tempHandle,
&tempRect);
    if (PtInRect(mousePoint, &tempRect)) {
        /* We're in the scroll bar. */
        /* Now, what does that mean???? */
        /* Well, the Dialog Manager will automatically call FindControl and
TrackControl */
        /* and set the control value (in the case of scroll thumbs) */
        /* on controls added to your dialog, and in many cases that's all you're
going */
        /* to need. */
        /* But, ModalDialog does NOT pass back a part code, so if the userPerson
*/
        /* clicked on the thumb or arrows of the scroll bar, you won't know,
you'll */
        /* just know that the  scroll bar was clicked in.*/
        /* That's not enough, so we'll to an initial check to see where the
control */
        /* was hit */
        thePart = FindControl(mousePoint, inputDialog, &returnedControl);
        /* if the hit was in an arrow or page area, we'll handle it ourselfs */
        if (thePart != inThumb) {
            TrackControl(returnedControl, mousePoint, (ProcPtr)DoScrollArrows);
            returnVal = true;
        }
        /* if it was in the thumb, we'll just fall through and let the Dialog
Manager */
        /* handle it for us */
    }




/* This little routine adjusts the scroll bar during TrackControl */
pascal void DoScrollArrows(ControlHandle theControl, short thePart)
{
    short currentVal = GetCtlValue(theControl);
    short offSet = 0;
    switch (thePart) {
        case inUpButton:
            offSet = -1;
            break;
        case inDownButton:
            offSet = 1;
            break;
        case inPageUp:
            offSet = -3;
            break;
        case inPageDown:
            offSet = 3;
            break;

    }
    /* set the control value to the new one, as long as it doesn't pass
limits */
    currentVal += offSet;
    if (currentVal < 1)
        currentVal = 1;
    if (currentVal > 10)
        currentVal = 10;
    SetCtlValue(theControl, currentVal);

} /* end DoScrollArrows */

<TR>
Somewhere, sometime

SPA FON

---------------------------

End of C.S.M.P. Digest
**********************


ˇ